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The MAILING DATE of this communication appears on tho cover sheet with the correspondence address - 
Period for Reply 

A SHORTENED STATUTORY PERIOD FOR REPLY IS SET TO EXPIRE 3 MONTH(S) FROM 
THE MAILING DATE OF THIS COMMUNICATION. 

- Extensions of time may be available under the provisions of 37 CFR 1.136(a). In no event, however, may a reply be timely filed 
after SIX (6) MONTHS from the mailing date of this communication. 

- If the period for reply specified above is less than thirty (30) days, a reply within the statutory minimum of thirty (30) days will be considered timely. 

- If NO period for reply is specified above, the maximum statutory period will apply and will expire SIX (6) MONTHS from the mailing date of this communication. 

- Failure to reply within the set or extended period for reply will, by statute, cause the application to become ABANDONED (35 U.S.C. § 133). 

- Any reply received by the Office later than three months after the mailing date of this communication, even if timely filed, may reduce any' 
earned patent term adjustment. See 37 CFR 1.704(b). 

Status 

1 )D Responsive to communication(s) filed on . 



2a)D This action is FINAL. 2b)E3 This action is non-final. 

3) D Since this application is in condition for allowance except for formal matters, prosecution as to the merits is 

closed in accordance with the practice under Ex parte Qyayle, 1935 CD. 1 1, 453 O.G. 213. 

Disposition of Claims 

4) IE Claim(s) 1-31 is/are pending in the application. 

4a) Of the above claim(s) is/are withdrawn from consideration. 

5) D Claim(s) is/are allowed. 

6) [3 Claim(s) 1-28,30 and 31 is/are rejected. 

7) 13 Claims 1. 3.13.17.22.29.31 is/are objected to. 

8) D Claim(s) are subject to restriction and/or election requirement. 

Application Papers 

9) 13 The specification is objected to by the Examiner. 

10) 13 The drawing(s) filed on 15 August 2001 is/are: a)D accepted or b)E3 objected to by the Examiner. 

Applicant may not request that any objection to the drawing(s) be held in abeyance. See 37 CFR 185(a). 
Replacement drawing sheet(s) including the correction is required if the drawing(s) is objected to. See 37 CFR 1.121(d). 

1 1) D The oath or declaration is objected to by the Examiner. Note the attached Office Action or form PTO-152. 
Priority under 35 U.S.C. §§ 1 1 9 and 1 20 

12) D Acknowledgment is made of a claim for foreign priority under 35 U.S.C. § 1 19(a)-(d) or (f). 

a)Cl All b)CH Some*c)D None of: 

1 .□ Certified copies of the priority documents have been received. 

2. Q Certified copies of the priority documents have been received in Application No. . 

3. D Copies of the certified copies of the priority documents have been received in this National Stage 

application from the International Bureau (PCT Rule 17.2(a)). 
* See the attached detailed Office action for a list of the certified copies not received. 

13) 13 Acknowledgment is made of a claim for domestic priority under 35 U.S.C. § 119(e) (to a provisional application) 

since a specific reference was included in the first sentence of the specification or in an Application Data Sheet. 
37 CFR 1.78. 

a) □ The translation of the foreign language provisional application has been received. 

14) D Acknowledgment is made of a claim for domestic priority under 35 U.S.C. §§ 120 and/or 121 since a specific 

reference was included in the first sentence of the specification or in an Application Data Sheet. 37 CFR 1.78. 
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DETAILED ACTION 



Priority 



1 .1 Applicant's claim for domestic priority under 35 U.S.C. 1 19(e) is acknowledged. 



2.1 The drawings are objected to because the description of figure 1a on lines 4 of 
paragraph 42 on page 1 1 describe the service controller as 106b and bicontroller as 
106a. Figure 1a mislabels the two controllers as 106a and 106b, respectively. Based 
on other references in the specifications to the controllers, it appears that the reference 
numbers in the specifications on the above cited lines should be changed. 

2.2 The drawings are objected to as failing to comply with 37 CFR 1 .84(p)(5) 
because they include the following reference sign(s) not mentioned in the description: 
reference 420 of figure 4b. 

2.3 The drawings are objected to as failing to comply with 37 CFR 1 .84(p)(5) 
because they do not include the following reference sign(s) mentioned in the 
description: reference 710 of figure 7. It seems that the xml parser, should remain 
labeled 134, in figure 7 and that reference 710 on line 5 of paragraph 1 15 of page 38, 
should be changed to 134. 

2.4 The drawings are objected to as failing to comply with 37 CFR 1 .84(p)(5) 
because they do not include the following reference sign(s) mentioned in the 
description: reference 1014 of figure 10b. 

A proposed drawing correction, corrected drawings, or amendment to the 
specification to add the reference sign(s) in the description, are required in reply to the 



Drawings 
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Office action to avoid abandonment of the application. The objection to the drawings will 
not be held in abeyance. 

Specification 

3.1 The abstract of the disclosure is objected to because on lines 5-6 the reference 
to the checksum value (407) is said to be placed in an integrity element (402), the figure 
associated with the abstract (figure 4a) does not clearly show that said checksum value 
of window A is within integrity element 402. The Examiner acknowledges that integrity 
elements a (402), b (404), and c (406) are all identical in makeup and therefore 
suggests that the reference numbers in the abstract, or the abstract itself, be changed 
to reflect the diagram depicted in figure 4a. A suggestion is to simply change 
references of "window (401 a)" to "window (401 b)" and to change all references of 
"integrity element (402)" to "integrity element (404)." 

. Correction is required. See MPEP § 608.01(b). 

3.2 The disclosure is objected to because of the following informalities: the status 
and serial numbers of nonprovisional related application(s) (whether patented or 
abandoned) listed on page 1 of the specifications should be included. If a related 

application has become a patent, the expression "now Patent No. " should follow 

the filing date of the related application. If a related application has become 
abandoned, the expression "now abandoned" should follow the filing date of the related 
application. 
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3.3 The use of the trademarks "Bluetooth", "Palm Pilot", and "iPAQ Blackberry" has 
been noted in this application. It should be capitalized wherever it appears and be 
accompanied by the generic terminology. 

Although the use of trademarks is permissible in patent applications, the 
proprietary nature of the marks should be respected and every effort made to prevent 
their use in any manner which might adversely affect their validity as trademarks. 

3.4 The disclosure is objected to because of the following informalities: the phrase 
"executable code" has been unnecessarily repeated twice on line 2 of paragraph 16 on 
page 7. 

3.5 Claim 1 is objected to because of the following informalities: 

• line 15 recites: " whereby ...." Such recitation is non- functional language, 
and as a result, is not given patentable weight. It has been held that 
functional "whereby" statement does not define any structure and 
accordingly cannot serve to distinguish in re Mason, 1 14 USPQ, 44 CCPA 
937 (1957). The "whereby" should be changed to "wherein." 

3.6 Claims 3. 13. 17. 22. 29. and 31 are objected to because of the following 
informalities: the claims refer to the term "XML" which has not been defined in the 
specifications. 

Appropriate corrections are required. 
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Claim Rejections - 35 USC § 103 



4!1 The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 

obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed 
or described as set forth in section 102 of this title, if the differences between the 
subject matter sought to be patented and the prior art are such that the subject 
matter as a whole would have been obvious at the time the invention was made 
to a person having ordinary skill in the art to which said subject matter pertains. 
Patentability shall not be negatived by the manner in which the invention was 
made. 

This application currently names joint inventors. In considering patentability of 
the claims under 35 U.S.C. 103(a), the examiner presumes that the subject matter of 
the various claims was commonly owned at the time any inventions covered therein 
were made absent any evidence to the contrary. Applicant is advised of the obligation 
under 37 CFR 1 .56 to point out the inventor and invention dates of each claim that was 
not commonly owned at the time a later invention was made in order for the examiner to 
consider the applicability of 35 U.S.C. 103(c) and potential 35 U.S.C. 102(e), (f) or (g) 
prior art under 35 U.S.C. 103(a). 

4.2 Claim(s) 1-3 is/are rejected under 35 U.S.C. 103(a) as being unpatentable over 
RFC 793 - Transmission Control Protocol Specification (hereinafter TCP). 
As per claim 1 

TCP substantially teaches of creating and transmitting data signals (i.e. 
segments/packets/frames) through a communication medium to receivers, see 
paragraph 1 of page 4. TCP further teaches of parsing (or packeting or packaging) 
bytes into frames (or packets) containing a subset of the bytes, see paragraph 1 of page 
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4. TCP further teaches of computing a checksum over the data, see Checksum 
paragraph on page 16. TCP further teaches of providing an integrity element, see 
pages 15-17, which the Examiner is interpreting as a header since it is essentially made 
of data (i.e. checksum, size, etc..) that will help determine the validity of the data frame. 
On pages 15-17, TCP teaches of an integrity element (header) that contains the 
checksum and how the integrity element (header) encapsulates (or associated with) one 
frame (or packet). On page 4, paragraph 3 teaches how the integrity element (header), 
specifically the checksum, can be used to determine if the received frame/data subset 
(or packet) is intact/valid or damaged. Further, in paragraph 1 of page 15, TCP teaches 
how the header and data are sent together as segments (i.e. broadcast signals). In 
paragraph 1 of page 4, TCP further teaches that the broadcast signals (i.e. segments) 
are transferred in both directions, hence TCP teaches the limitation of transmitting 
signals to receivers. In paragraph 6 of page 40, TCP further teaches of transmitting the 
signals over an established connection, hence TCP teaches the limitation of transmitting 
through communication medium to the device. 

While TCP does not explicitly teach of apparatuses or devices to carry out the 
methods taught, it would have been obvious to one of ordinary skill in the art at the time 
the invention was made to implement the teachings in some type hardware once the 
method is know/determined. 

As per claim 2. 

TCP further teaches of an integrity element (header) that comprises a size value, 
see page 17, paragraph 2 where the TCP length is described. Further, it would have 
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been obvious to one of ordinary skill in the art to include both the checksum operation 
and seed value. If these values were not previously agreed upon by the communication 
devices, then one of ordinary skill in the art would obviously want to transmit these 
values so as to allow the receiving device to be able to calculate the checksum and 
validate/invalidate successfully. 

Further, with respect to the operator to compute the checksum, as is common in 
the art, checksums are typically calculated with XORs or summing in mod 2 arithmetic. 
Further, the specifications do not teach of any checksum calculation techniques other 
than XOR when disclosing known techniques to calculate the checksum. Therefore the 
need to transmit the operator along with the integrity element is not clear (especially if 
the only admitted operation is XOR). While it is understood that checksum can be 
calculated various specific ways (i.e. CRC), the operator used is typically the XOR. 

It is further unclear why the checksum operation and seed values are not 
uniformly agreed upon beforehand so as to save bandwidth (i.e. have to transmit less 
bits) and save calculation time (i.e. immediately calculate checksum upon receiving as 
opposed to receiving the packet and read out the operation and then calculate the 
checksum). 

As per claim 3, 

It would have been obvious to one of ordinary skill in the art at the time the 
invention was made to have the data signal contain an XML element. Essentially, this is 
akin to a user on a network, possibly the internet, requesting an XML document (which 
obviously contains XML elements), having the document framed (or packeted up) and 



Application/Control Number: 09/930,004 Page 8 

Art Unit: 2133 

transmitted off to the receiver. Simply put, the data that the frame/packet contains can 
be comprised of almost any type of transferable data, (i.e. XML document with XML 
elements, HTML document etc). 

4.3 Claim(s) 4 is/are rejected under 35 U.S.C. 103(a) as being unpatentable over 
RFC 793 - Transmission Control Protocol Specification (hereinafter TCP) in view of 
admitted prior art "Specifications" (hereinafter Specs). 

As per claim 4, 

TCP as noted above in claim 1 and later in claim 3 substantially teaches of the 
limitations of claim 4. TCP does not teach of transmitting the signal as a diffuse infrared 
signal. Nonetheless, TCP does teach of establishing communication connections. 

Specs, in an analogous art, teaches of diffuse optical communication as a 
common optical communication protocol, see paragraph 88 on page 28. 

It would have been obvious to one of ordinary skill in the art at the time the 
invention was made to transmit the frames/packets/broadcast signal of TCP using the 
optical communication protocol. This modification would have been obvious because 
one of ordinary skill in the art would have been motivated by the suggestion provided by 
Specs that diffuse optical communication protocol is a commonly used protocol and 
hence communication method. 

4.4 Claim(s) 5-9 is/are rejected under 35 U.S.C. 103(a) as being unpatentable over 
RFC 793 - Transmission Control Protocol Specification (hereinafter TCP). 

As per claim 5, 
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TCP substantially teaches of exchanging (and hence transmitting and receiving) 
segments/packets/data signals having a plurality of bytes in paragraph 1 of page 4 and 
paragraph 6 of page 40. TCP further teaches of creating frames/packets and headers 
(integrity elements) to transmit data, see paragraph 1 on page 4 and pages 15-17, and 
of using the checksum to ensure reliability, see paragraph 3, page 4. By teaching of 
creating the data and communicating/transferring it in a specific manner, the Examiner 
is interpreting that TCP is teaching of both how to send and receive the data. When 
read in this light, it is clear that if TCP teaches of how to create frames (packets) and 
associated integrity elements (headers) and how to combine the frames and integrity 
elements (i.e. append the header to the packet), then TCP teaches how to detect and 
separate packets/frames as well. Further, with TCP teaching of headers and what they 
are comprised of on pages 15-17, it is clear that TCP teaches of determining the 
contents of the integrity element (header). Further, TCP explicitly teaches of using the 
checksum (which is one of the contents of the header/integrity element) to disregard 
damaged segments/packets, see paragraph 3 on page 4. 

While TCP does not explicitly teach of apparatuses or devices to carry out the 
methods taught, it would have been obvious to one of ordinary skill in the art at the time 
the invention was made to implement the teachings in some type hardware once the 
method is know/determined. 

As per claim 6. 

TCP substantially teaches, as noted above in claim 5, the limitations of claim 6. 
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With respect to the limitations of claim 6, TCP further teaches of a checksum that 
is calculated over its associated frame/packet, see pages 15-17 and specifically the 
Checksum paragraph of page 16. 

As per claims 7 and 8, 

TCP substantially teaches, as noted above in claim 5, the limitations of claim 7. 

With respect to the limitations of claim 7, TCP further teaches of checking a 
checksum at the receiver to ensure that the segment is not damaged, see paragraph 3 
of page 4. Clearly, if the checksum is calculated upon receipt and matches the 
transmitted checksum, then the segment/frame/packet will be validated, otherwise, 
when the two checksums don't match, the "damaged" one will be discarded or 
invalidated. 

As per claim 9, 

TCP substantially teaches, as noted above in claim 5, the limitations of claim 9. 

With respect to the limitations of claim 9, TCP further teaches of an integrity 
element (header) that comprises a size value, see page 17, paragraph 2 where the TCP 
length is described. Further, it would have been obvious to one of ordinary skill in the 
art to include both the checksum operation and seed value. If these values were not 
previously agreed upon by the communication devices, then one of ordinary skill in the 
art would obviously want to transmit these values so as to allow the receiving device to 
be able to calculate the checksum and validate/invalidate successfully. 

Further, with respect to the operator to compute the checksum, as is common in 
the art, checksums are typically calculated with XORs or summing in mod 2 arithmetic. 
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Further, the specifications do not teach of any checksum calculation techniques other 
than XOR when disclosing known techniques to calculate, the checksum. Therefore the 
need to transmit the operator along with the integrity element is not clear (especially if 
the only admitted operation is XOR). While it is understood that checksum can be 
calculated various specific ways (i.e. CRC), the operator used is typically the XOR. 

It is further unclear why the checksum operation and seed values are not 
uniformly agreed upon beforehand so as to save bandwidth (i.e. have to transmit less 
bits) and save calculation time (i.e. immediately calculate checksum upon receiving as 
opposed to receiving the packet and read out the operation and then calculate the 
checksum). 

4.5 Claim(s) 10 and 11 is/are rejected under 35 U.S.C. 103(a) as being unpatentable 
over RFC 793 - Transmission Control Protocol Specification (hereinafter TCP) in view 
of admitted prior art "Specifications" (hereinafter Specs). 
As per claim 10 

TCP, as noted above in claim 5, substantially teaches of the limitations of claim 
10. TCP does not teach of transmitting the signal as a diffuse infrared signal. 
Nonetheless, TCP does teach of establishing communication connections. 

Specs, in an analogous art, teaches of diffuse optical communication as a 
common optical communication protocol, see lines 3-6 of paragraph 88 on page 28. 

It would have been obvious to one of ordinary skill in the art at the time the 
invention was made to transmit the frames/packets/broadcast signal of TCP using the 
optical communication protocol. This modification would have been obvious because 
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one of ordinary skill in the art would have been motivated by the suggestion provided by 
Specs that diffuse optical communication protocol is a commonly used protocol and 
hence communication method. 
As per claim 11. 

TCP, as noted above in claim 5 and later in claim 10, substantially teaches of the 
limitations of claim 1 1 . TCP does not teach of data signal being created by modulating 
an electric light. 

Specs, in an analogous art, teaches of modulating an electric light to generate 
optical signals as being known in the art, see lines 1-5 of paragraph 161 of page 55. 

It would have been obvious to one of ordinary skill in the art at the time the 
invention was made to create frames/packets/broadcast signal of TCP by modulating an 
electric light. This modification would have been obvious to one of ordinary skill in the 
art would because one skilled in the art would have known of the techniques as 
mentioned by Specs. Further, since Specs discloses that the techniques are known in 
the art, one skilled in the art would readily be able to modulate light so as to generate 
the optical signals with which the data signals are transferred over. 
4.6 Claim(s) 12,13, 15 is/are rejected under 35 U.S.C. 103(a) as being unpatentable 
over RFC 793 -Transmission Control Protocol Specification (hereinafter TCP). 

As per claim 12, 

TCP substantially teaches of creating and transmitting data signals (i.e. 
packets/frames) through a communication medium to receivers see paragraph 1 of 
page 4. TCP further teaches of parsing (or packeting or packaging) bytes into frames 
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(or packets) containing a subset of the bytes, see paragraph 1 of page 4. TCP further 
teaches of computing a checksum over the data, see Checksum paragraph on page 16. 
TCP further teaches of providing an integrity element, see pages 15-17, which the 
Examiner is interpreting as a header since it is essentially made of data (i.e. checksum, 
size, etc.) that will help determine the validity of the data frame. On pages 15-17, TCP 
teaches of an integrity element (header) that contains the checksum and how the 
integrity element (header) encapsulates (or associated with) one frame (or packet). On 
page 4, paragraph 3 teaches how the integrity element (header), specifically the 
checksum, can be used to determine if the received frame/data subset (or packet) is 
intact/valid or damaged. Further, in paragraph 1 of page 15, TCP teaches how the 
header and data are sent together as segments (i.e. broadcast signals). In paragraph 1 
of page 4, TCP further teaches that the broadcast signals (i.e. segments) are 
transferred in both directions, hence TCP teaches the limitation of transmitting signals to 
receivers. In paragraph 6 of page 40, TCP further teaches of transmitting the signals 
over an established connection, hence TCP teaches the limitation of transmitting 
through communication medium to the device. 

While TCP does not explicitly teach of making the transmission available for 
handheld devices, it would have been obvious to one of ordinary skill in the art at the 
time the invention was made to make the broadcast signal available for a handheld 
device. Handheld devices (i.e. PDAs) are essentially handheld computers that can 
process information whether received via their infrared port or through their physical 
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port. One skilled in the art would obviously want a handheld device to be able to 
receive information so as to be able to communicate with it. 

Further, while TCP does not explicitly teach of apparatuses, devices, or computer 
readable executable code embedded to carry out the methods taught, it would have 
been obvious to one of ordinary skill in the art at the time the invention was made to 
implement the teachings in some type of hardware or computer executable code once 
the method is known/determined. 

As per claim 13, 

It would have been obvious to one of ordinary skill in the art at the time the 
invention was made to have the data signal contain an XML element. Essentially, this is 
akin to a user on a network, possibly the internet, requesting an XML document (which 
obviously contains XML elements), having the document framed (or packeted up) and 
transmitted off to the receiver. Simply put, the data that the frame/packet contains can 
be comprised of almost any type of transferable data, (i.e. XML document with XML 
elements, HTML document etc). 

As per claim 15, 

TCP further teaches of an integrity element (header) that comprises a size value, 
see page 17, paragraph 2 where the TCP length is described. Further, it would have 
been obvious to one of ordinary skill in the art to include both the checksum operation 
and seed value. If these values were not previously agreed upon by the communication 
devices, then one of ordinary skill in the art would obviously want to transmit these 
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values so as to allow the receiving device to be able to calculate the checksum and 
validate/invalidate successfully. 

Further, with respect to the operator to compute the checksum, as is common in 
the art, checksums are typically calculated with XORs or summing in mod 2 arithmetic. 
Further, the specifications do not teach of any checksum calculation techniques other 
than XOR when speaking known techniques to calculate the checksum. Therefore the 
need to transmit the operator along with the integrity element is not clear (especially if 
the only admitted operation is XOR). While it is understood that checksum can be 
calculated various specific ways (i.e. CRC), the operator used is typically the XOR. 
4.7 Claim(s) 14 is/are rejected under 35 U.S.C. 103(a) as being unpatentable over 
RFC 793 - Transmission Control Protocol Specification (hereinafter TCP) in view of 
admitted prior art "Specifications" (hereinafter Specs). 

As per claim 14, 

TCP as noted above in claim 12 substantially teaches of the limitations of claim 
14. TCP does not teach of transmitting the signal as a diffuse infrared signal. 
Nonetheless, TCP does teach of establishing communication connections. 

Specs, in an analogous art, teaches of diffuse optical communication as a 
common optical communication protocol, see paragraph 88 on page 28. 

It would have been obvious to one of ordinary skill in the art at the time the 
invention was made to transmit the frames/packets/broadcast signal of TCP using the 
optical communication protocol. This modification would have been obvious because 
one of ordinary skill in the art would have been motivated by the suggestion provided by 
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Specs that diffuse optical communication protocol is a commonly used protocol and 
hence communication method. 

4.8 Claim(s) 16-19 is/are rejected under 35 U.S.C. 1 03(a) as being unpatentable 
over RFC 793 - Transmission Control Protocol Specification (hereinafter TCP). 
As per claim 16. 

TCP substantially teaches of exchanging (and hence transmitting and receiving) 
segments/packets/data signals having a plurality of bytes in paragraph 1 of page 4 and 
paragraph 6 of page 40. TCP further teaches of creating frames/packets and headers 
(integrity elements) to transmit data, see paragraph 1 on page 4 and pages 15-17 and 
of using the checksum to ensure reliability, see paragraph 3, page 4. By teaching of 
creating the data and communicating/transferring it in a specific manner, the Examiner 
is interpreting that TCP is teaching of both how to send and receive the data. When 
read in this light, it is clear that if TCP teaches of how to create frames (packets) and 
associated integrity elements (headers) and how to combine the frames and integrity 
elements (i.e. append the header to the packet), then TCP teaches how to detect and 
separate packets as well. Further, with TCP teaching of headers and what they are 
comprised of on pages 15-17, it is clear that TCP teaches of determining the contents of 
the integrity element (header). Further, TCP explicitly teaches of using the checksum 
(which is one of the contents of the header/integrity element) to disregard damaged 
segments/packets, see paragraph 3 on page 4. TCP further teaches of a checksum 
that is calculated over its associated frame/packet, see pages 15-17 and specifically the 
Checksum paragraph of page 16. TCP further teaches of checking a checksum at the 
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receiver to ensure that the segment is not damaged, see paragraph 3 of page 4. 
Clearly, if the checksum is calculated upon receipt and matches the transmitted 
checksum, then the segment/frame/packet will be validated, otherwise, when the two 
checksums don't match, the "damaged" one will be discarded or invalidated. Further, 
TCP teaches of passing the frames/segments/packets on if the checksums match, see 
paragraph 3 of page 4, specifically where TCP mentions discarding damaged segments 
(i.e. segments in which the checksums do not match) and keeping/passing on those 
that do match. 

While TCP does not explicitly teach of apparatuses, devices, or computer 
readable executable code embedded to carry out the methods taught, it would have 
been obvious to one of ordinary skill in the art at the time the invention was made to 
implement the teachings in some type of hardware or computer executable code once 
the method is known/determined. 

As per claim 17, 

It would have been obvious to one of ordinary skill in the art at the time the 
invention was made to have the data signal contain an XML element. Essentially, this is 
akin to a user on a network, possibly the internet, requesting an XML document (which 
obviously contains XML elements), having the document framed (or packeted up) and 
transmitted off to the receiver. Simply put, the data that the frame/packet contains can 
be comprised of almost any type of transferable data, (i.e. XML document with XML 
elements, HTML document etc). 

As per claim 18, 



Application/Control Number: 09/930,004 Page 18 

Art Unit: 2133 

TCP further teaches of discarding the frames/segments/packets on if the 
checksums match, see paragraph 3 of page 4, specifically where TCP mentions 
discarding damaged segments (i.e. segments in which the checksums do not match). 

As per claim 19, 

TCP further teaches of an integrity element (header) that comprises a size value, 
see page 17, paragraph 2 where the TCP length is described. Further, it would have 
been obvious to one of ordinary skill in the art to include both the checksum operation 
and seed value. If these values were not previously agreed upon by the communication 
devices, then one of ordinary skill in the art would obviously want to transmit these 
values so as to allow the receiving device to be able to calculate the checksum and 
validate/invalidate successfully. 

Further, with respect to the operator to compute the checksum, as is common in 
the art, checksums are typically calculated with XORs or summing in mod 2 arithmetic. 
Further, the specifications do not teach of any checksum calculation techniques other 
than XOR when speaking known techniques to calculate the checksum. Therefore the 
need to transmit the operator along with the integrity element is not clear (especially if 
the only admitted operation is XOR). While it is understood that checksum can be 
calculated various specific ways (i.e. CRC), the operator used is typically the XOR. 

It is further unclear why the checksum operation and seed values are not 
uniformly agreed upon beforehand so as to save bandwidth (i.e. have to transmit less 
bits) and save calculation time (i.e. immediately calculate checksum upon receiving as 
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opposed to receiving the packet and read out the operation and then calculate the 
checksum). 

4.9 Claim(s) 20-22 is/are rejected under 35 U.S.C. 1 03(a) as being unpatentable 
over RFC 793 - Transmission Control Protocol Specification (hereinafter TCP). 
As per claim 20, 

TCP substantially teaches of creating and transmitting data signals (i.e. 
packets/frames) through a communication medium to receivers see paragraph 1 of 
page 4. TCP further teaches of parsing (or packeting or packaging) bytes into frames 
(or packets) containing a subset of the bytes, see paragraph 1 of page 4. TCP further 
teaches of computing a checksum over the data, see Checksum paragraph on page 16. 
TCP further teaches of providing an integrity element, see pages 15-17, which the 
Examiner is interpreting as a header since it is essentially made of data (i.e. checksum, 
size, etc..) that will help determine the validity of the data frame. On pages 15-17, TCP 
teaches of an integrity element (header) that contains the checksum and how the 
integrity element (header) encapsulates (or associated with) one frame (or packet). On 
page 4, paragraph 3 teaches how the integrity element (header), specifically the 
checksum, can be used to determine if the received frame/data subset (or packet) is 
intact/valid or damaged. Further, in paragraph 1 of page 15, TCP teaches how the 
header and data are sent together as segments (i.e. broadcast signals). In paragraph 1 
of page 4, TCP further teaches that the broadcast signals (i.e. segments) are 
transferred in both directions, hence TCP teaches the limitation of transmitting signals to 
receivers. In paragraph 6 of page 40, TCP further teaches of transmitting the signals 
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over an established connection, hence TCP teaches the limitation of transmitting 
through communication medium to the device. 

While TCP does not explicitly teach of making the broadcast signal available for 
transmission to a receiving device, it would have been obvious to one of ordinary skill in 
the art at the time the invention was made to make the broadcast signal available for the 
transmission. TCP, in paragraph 6 of page 40, does teach of a connection that is 
established and data is communicated between senders and receivers. Therefore 
making the signal available for transmission to a receiving device must occur since TCP 
teaches that a connection is established and data/segments are 
communicated/exchanged. 

As per claim 21, 

TCP further teaches of an integrity element (header) that comprises a size value, 
see page 17, paragraph 2 where the TCP length is described. Further, it would have 
been obvious to one of ordinary skill in the art to include both the checksum operation 
and seed value. If these values were not previously agreed upon by the communication 
devices, then one of ordinary skill in the art would obviously want to transmit these 
values so as to allow the receiving device to be able to calculate the checksum and 
validate/invalidate successfully. 

Further, with respect to the operator to compute the checksum, as is common in 
the art, checksums are typically calculated with XORs or summing in mod 2 arithmetic. 
Further, the specifications do not teach of any checksum calculation techniques other 
than XOR when speaking known techniques to calculate the checksum. Therefore the 
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need to transmit the operator along with the integrity element is not clear (especially if 
the only admitted operation is XOR). While it is understood that checksum can be 
calculated various specific ways (i.e. CRC), the operator used is typically the XOR. 

It is further unclear why the checksum operation and seed values are not 
uniformly agreed upon beforehand so as to save bandwidth (i.e. have to transmit less 
bits) and save calculation time (i.e. immediately calculate checksum upon receiving as 
opposed to receiving the packet and read out the operation and then calculate the 
checksum). 

As per claim 22. 

It would have been obvious to one of ordinary skill in the art at the time the 
invention was made to have the data signal contain an XML element. Essentially, this is 
akin to a user on a network, possibly the internet, requesting an XML document (which 
obviously contains XML elements), having the document framed (or packeted up) and 
transmitted off to the receiver. Simply put, the data that the frame/packet contains can 
be comprised of almost any type of transferable data, (i.e. XML document with XML 
elements, HTML document etc). 

4.10 Claim(s) 23 and 24 is/are rejected under 35 U.S.C. 103(a) as being unpatentable 
over RFC 793 - Transmission Control Protocol Specification (hereinafter TCP) in view 
of admitted prior art "Specifications" (hereinafter Specs). 
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As per claim 23 

TCP, as taught above in claim 20, substantially teaches of the limitations of claim 

23. TCP, however, does not teach of transmitting the signal as a diffuse infrared signal. 
Nonetheless, TCP does teach of establishing communication connections. 

Specs, in an analogous art, teaches of diffuse optical communication as a 
common optical communication protocol, see line see lines 3-6 of paragraph 88 on 
page 28. 

It would have been obvious to one of ordinary skill in the art at the time the 
invention was made to transmit the frames/packets/broadcast signal of TCP using the 
optical communication protocol. This modification would have been obvious because 
one of ordinary skill in the art would have been motivated by the suggestion provided by 
Specs that diffuse optical communication protocol is a commonly used protocol and 
hence communication method. 

As per claim 24. 

TCP, as taught above in claim 20, substantially teaches of the limitations of claim 

24. TCP does not teach of data signal being created by modulating an electric light. 

Specs, in an analogous art, teaches of modulating an electric light to generate 
optical signals as being known in the art, see line see lines 1-5 of paragraph 161 of 
page 55. 

It would have been obvious to one of ordinary skill in the art at the time the 
invention was made to create frames/packets/broadcast signal of TCP by modulating an 
electric light. This modification would have been obvious to one of ordinary skill in the 
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art would because one skilled in the art would have known of the techniques as 

mentioned by Specs. Further, since Specs discloses that the techniques are known in 

the art, one skilled in the art would readily be able to modulate light so as to generate 

the optical signals with which the data signals are transferred over. 

4.1 1 Claim(s) 25-27 and 31 is/are rejected under 35 U.S.C. 103(a) as being 

unpatentable over RFC 793 - Transmission Control Protocol Specification (hereinafter 

TCP). 

As per claim 25. 

TCP substantially teaches of exchanging (and hence transmitting and receiving) 
segments/packets/data signals having a plurality of bytes in paragraph 1 of page 4 and 
paragraph 6 of page 40. TCP further teaches of creating frames/packets and headers 
(integrity elements) to transmit data, see paragraph 1 on page 4 and pages 15-17 and 
of using the checksum to ensure reliability, see paragraph 3, page 4. By teaching of 
creating the data and communicating/transferring it in a specific manner, the Examiner 
is interpreting that TCP is teaching of both how to send and receive the data. When 
read in this light, it is clear that if TCP teaches of how to create frames (packets) and 
associated integrity elements (headers) and how to combine the frames and integrity 
elements (i.e. append the header to the packet), then TCP teaches how to detect and 
separate packets as well. Further, with TCP teaching of headers and what they are 
comprised of on pages 15-17, it is clear that TCP teaches of determining the contents of 
the integrity element (header). Further, TCP explicitly teaches of using the checksum 
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(which is one of the contents of the header/integrity element) to disregard damaged 
segments/packets, see paragraph 3 on page 4. 

While TCP does not explicitly teach of apparatuses or devices to carry out the 
methods taught, it would have been obvious to one of ordinary skill in the art at the time 
the invention was made to implement the teachings in some type hardware once the 
method is known/determined. 

As per claims 26 and 27. 

TCP substantially teaches, as noted above in claim 25, the limitations of claims 
26 and 27. With respect to the limitations of claims 26 and 27, TCP further teaches of 
checking a checksum at the receiver to ensure that the segment is not damaged, see 
paragraph 3 of page 4. Clearly, if the checksum is calculated upon receipt and matches 
the transmitted checksum, then the segment/frame/packet will be validated, otherwise, 
when the two checksums don't match, the "damaged" one will be discarded or 
invalidated. 

As per claim 31. 

It would have been obvious to one of ordinary skill in the art at the time the 
invention was made to have the data signal contain an XML element. Essentially, this is 
akin to a user on a network, possibly the internet, requesting an XML document (which 
obviously contains XML elements), having the document framed (or packeted up) and 
transmitted off to the receiver. Simply put, the data that the frame/packet contains can 
be comprised of almost any type of transferable data, (i.e. XML document with XML 
elements, HTML document etc). 
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4.12 Claim(s) 28, 30 is/are rejected under 35 U.S.C. 103(a) as being unpatentable 
over RFC 793 - Transmission Control Protocol Specification (hereinafter TCP). 
As per claim 28, 

TCP substantially teaches of creating and transmitting data signals (i.e. 
packets/frames) through a communication medium to receivers see paragraph 1 of 
page 4. TCP further teaches of parsing (or packeting or packaging) bytes into frames 
(or packets) containing a subset of the bytes, see paragraph 1 of page 4. TCP further 
teaches of computing a checksum over the data, see Checksum paragraph on page 16. 
TCP further teaches of providing an integrity element, see pages 15-17, which the 
Examiner is interpreting as a header since it is essentially made of data (i.e. checksum, 
size, etc.) that will help determine the validity of the data frame. On pages 15-17, TCP 
teaches of an integrity element (header) that contains the checksum and how the 
integrity element (header) encapsulates (or associated with) one frame (or packet). On 
page 4, paragraph 3 teaches how the integrity element (header), specifically the 
checksum, can be used to determine if the received frame/data subset (or packet) is 
intact/valid or damaged. Further, in paragraph 1 of page 15, TCP teaches how the 
header and data are sent together as segments (i.e. broadcast signals). In paragraph 1 
of page 4, TCP further teaches that the broadcast signals (i.e. segments) are 
transferred in both directions, hence TCP teaches the limitation of transmitting signals to 
receivers. TCP further teaches of checking a checksum at the receiver to ensure that 
the segment is not damaged, see paragraph 3 of page 4. Clearly, if the checksum is 
calculated upon receipt and matches the transmitted checksum, then the 
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segment/frame/packet will be validated, otherwise, when the two checksums don't 
match, the "damaged" one will be discarded or invalidated. 

While TCP does not explicitly teach of the data signal being used to modify the 
operation of the receiving device, TCP does teach of the use of acknowledgements 
(ACKs) to inform the sender that a packet has been received, see paragraph 1 of page 
10, and of the use of PUSH commands, see paragraphs 5-7 of page 12, to change 
(modify) the operation of the receiver to "push." the data immediately. Therefore, 
through the use of ACKs to inform the receiver to send newer, or older segments, and 
the use of PUSH commands to pass the data on immediately, TCP teaches of 
modifying the operation of the receiver (and sender too). 

As per claim 30. 

TCP further teaches of an integrity element (header) that comprises a size value, 
see page 17, paragraph 2 where the TCP length is described. Further, it would have 
been obvious to one of ordinary skill in the art to include both the checksum operation 
and seed value. If these values were not previously agreed upon by the communication 
devices, then one of ordinary skill in the art would obviously want to transmit these 
values so as to allow the receiving device to be able to calculate the checksum and 
validate/invalidate successfully. 

Further, with respect to the operator to compute the checksum, as is common in 
the art, checksums are typically calculated with XORs or summing in mod 2 arithmetic. 
Further, the specifications do not teach of any checksum calculation techniques other 
than XOR when speaking known techniques to calculate the checksum. Therefore the 
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need to transmit the operator along with the integrity element is not clear (especially if 
the only admitted operation is XOR). While it is understood that checksum can be 
calculated various specific ways (i.e. CRC), the operator used is typically the XOR. 

It is further unclear why the checksum operation and seed values are not 
uniformly agreed upon beforehand so as to save bandwidth (i.e. have to transmit less 
bits) and save calculation time (i.e. immediately calculate checksum upon receiving as 
opposed to receiving the packet and read out the operation and then calculate the 
checksum). 



5.1 Claim 29 objected to as being dependent upon a rejected base claim, but would 
be allowable if rewritten in independent form including all of the limitations of the base 
claim and any intervening claims. 
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6.2 Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Marshall S Eng whose telephone number is (703) 305- 
4638. The examiner can normally be reached on M-F, 9:00 am to 5:30 pm. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Albert DeCady can be reached on (703) 305-9595. The fax phone number 
for the organization where this application or proceeding is assigned is (703) 872-9306. 

Any inquiry of a general nature or relating to the status of this application or 
proceeding should be directed to the receptionist whose telephone number is (703) 305- 
3900. 
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